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Really Hiding Cryptographic Keys in Software 

Abstract 

Many attempts have been made to construct tamper-resistant, secret-hiding software. In particular, many 
attempts have been made to hide private cryptographic keys in software.They have been notably ineffec- 
tive. This paper presents a far more powerfol approach to the key-hiding, tamper-proofing problem. The 
material forms part of a number of patent applications. 

It is widely believed that tamper-proof; secret-hiding software is impossible. We indicate compeUing rea- 
sons for changing this belief We then discuss various approaches to security problems, including the cur- 
rent crop of very weak software-based approaches. We then exemplify a much stronger approach to 
software-based security, using oyptogr^hic key hiding for tiie DES cipher as our specific example. 

Introduction 

""And stiU U moves. — Galileo's comment when told that the planetary motion he had observed with 
his telescope could not possibly exist, because it would be contrary to established doctrine. 

Many attempts have been made to construct tamper-resistant, secret-hiding software, and in particular, to 
hide private cryptographic keys in software which must perform actual enciyption or decryption. They 
have been notably ineffective. We present here a far more effective approach to the key-hiding, tamper- 
proofing problem. The methods described form part of a number of patent applications. 

There is a variety of uses for hiding cryptographic keys whidi are used during execution of an application. 
This is particularly true in connection with a broader strategy for generation of tamper-proo£ secret-hiding 
software. For example, consider the use of biometric information for identification purposes. It is undesir- 
U able to transmit biometric information, because it cannot be replaced when it is compromised (each person 

2 has a maximum of two thumbs, one voice, two retinas, and so on). If we store biometric information 

locally, encrypted with a key hidden in software, we can use a strategy over the network vsiiich both saves 
H bandwidth (biometric information tends to be bulky) and eliminates risk of compromise due to dissemina- 

H= tion of such non-replaceable data. 

D 

. 1= (The biometric data could not be decrypted by simply extracting the enciyption and decryption compo- 

^ nents fi-om the software, because we would employ subsidiary techniques to make separation into compo- 

nents a very hard problem. Moreover, we would employ subsidiary tamper-proofing, secret-hiding 
methods to ensure that comparisons of biometric data do not compromise it, even when the attacker has 
full debugging access, and that the behavior of the application performing such operations is not modifi- 
able in any way useful to the attacker. Hence the biometric information can be well protected both locally 
and globally.) 

There is no sense m even trying to do this, however, if it is impossible. Established doctrine, based on an 
unproven folk-theorem, says that tamper-proo^ secret-hiding software is impossible: given access to exe- 
cutable code, we can always modify its behavior to suit ourselves or extract its secrets. The hacker is 
omnipotent. After all, a program is just a form of data, wiiich anyone can change at will. Moreover, a pro- 
gram miist plainly reveal its semantics, because a program is neither more nor less nor other than an encod- 
ing of semantics, readable by a human, a compiler, an interpreter, or a computer of some kind. How, then, 
can software hide anything significant about itself in a truly effective way? 

However widely believed, this doctrine is nevertheless false. There is a widely-known phenomenon which 
disproves it but most fail to recognize that it is a counter-example to the folk theorem. Those ^^o have 
programmed in any large software project know that testing often reveals bugs which we can only fix by 
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discarding the offending components and replacing them with fresh ones, not by understanding and modi- 
fying them. Any attempts to remedy such bugs by modest changes to the offending components result in a 
seemingly endless variety of new bugs. Such components exhibit a resistance to comprehension or effec- 
tive change sufficient to fiiistrate even the most experienced, clever, and patient software experts. 

(Of course, in the large software context, tiie connectivity and opportunities for wide varieties of complex 
interactions are increased — but massive size is not the only way to increase them. A programmer who can 
truly extract all of the secrets of such a body of software, or bend its behavior to her will using only small 
incremental changes instead of much laiger rewrites, should have a highly lucrative career in upgrading 
legacy systenfis, developed at enormous cost, and otherwise destined for the scrap heap. My own decades 
of experience in iaige software projects have led me to believe that such folk do not exist.) 

Tamper-proof, secret-hiding software is software whidi exhibits the properties of the stubbornly misbehav- 
ing components mentioned above: it exhibits behavior which (1) cannot be understood or reverse-engi- 
neered using available time, tools, and human resources, and (2) cannot be modified without producing 
new imacceptable behavior using available time, tools, and human resources. That is, the software effec- 
tively (1) hides its secret data and algorithms, and (2) prevents modifications other than reduction of the 
program's behavior, or crucial portions diereof, to nonsense. 

The problem of generating tamp^-proof, secret-hiding versions of arbitrary programs is indeed a massive 
_ one, far beyond the scope of a single paper. Approaches required depend on tiie nature of the data (integral 

^ or floating; scalar, arrayed, or otiierwise structured; internal to tiie program or external in files and dOxes 

^ media), and the nature of the control strategy (object-oriented, procedural, or functional; serial, implicitly 

parallel, or explicitly parallel in various ways). Here, we focus specifically on the problem of hiding a DES 
(Data Encryption Standard) key in software, that is, of producing fully standard DES encryption and 
^ deci>'ption functions which use a secret key which is exceedingly difficult to extract fi-om the fimctions. 

lf\ The (patent pending) techniques used have high overheads compared to previous ^^proaches. However, 

^ they are also enormously more effective in hiding a secret key and frustrating targeted tampering. 

" One might think that tamper-proofing, in the sense of creating software which changes behavior drastically 

Yl in response to small changes, is irrelevant to secret-hiding, such as hiding a ayptographic key. Actually, it 

Y' is quite relevant: it makes perturbation-based analysis (analysis by examination of responses to small 

changes) much more difiicult. 



Previous Approaches Are Either Expensive or Weak 

Many approaches have been taken to the problems of secret-hiding and tamper-proofing: 

Hardware approaches have been proposed in profusion. These are generally inapplicable to the installed 
base of computers, and would be (or are) costly to administrate and deploy. 

A highly elaborate hardware-based x^proach — obviously totally inapplicable to the installed base of com- 
puters — \^ch hides instructions, data, and control flow, is presented in [OST 1992]. A hardware 
approach conceptually similar to a safe with a combination lock is presented in [MARX 1998]. 

Among hardware-based approaches, we have dangles and smart cards^ which move data and code inside a 
physical device. They are costly for administration and transport, compared to software-based ^proaches, 
where manufacture is virtually free and transport can be electronic. Moreover, due to structural limitations, 
smart cards have been far more vulnerable to penetration of their secrets than was hoped: news items 
describing incidents of penetration have been appearing on a regular basis. 

There have been many special-purpose tricks to prevent unauthorized software copying of software, 
including start-up code examining supposedly unused parts of an attached hard-disk, 'fingerprinting' par- 
ticular PC environments, and querying hardware, operating-system-provided, or network-provided identi- 



fiers. They have been defeated by hackers on a regular basis. As is well known, special-purpose copy 
programs wliich casually remove copy-protection from PC software in transit are available for a &irly 
modest price if you know where to ask. 

A software approach for computing with encrypted data is described in [AHI 1987]. This method hides the 
actual value of the data from the software doing the computation. The computations which are practical 
using this technique are restricted, of course. (For example, it is not well suited to DES key hiding.) In 
terms of obfiiscation, it is far superior to anything generally available in a commercial obfiiscator. 

(COL 1998-1] provides a method for concealing the intent of the control flow, and [COL 1998-2] provides 
more comprehensive proposals on obfuscation, together with methods for obfuscation of structured and 
object-oriented data. Again, these approaches are far superior to what is genially available in conmiercial 
obfuscation tools. 

There remains a weakness, however, ev«i in the methods proposed by [AHI 1987], [COL 1998-1], and 
[COL 1998-2]. Obfuscation and tamper-proofing are distinct problems. For example, consider removing 
password protection from an application by changing one branch from a conditional one to an uncondi- 
tional one. Plainly, this vulnerability cannot be eliminated efifectively by any amoimt of mere obfuscation 
— a patient hacker tracing the code will eventually find the ''pass, friend" / "begone, foe*' branch. We need 
other mediods to avoid single points of failure for tamper-proofing. The above metiiods are quite good for 
obfuscation^ but they are not nearly as effective for tamper-proofing. 
^ . . 

Q Existing general-purpose commercial software obfuscators use a variety of techniques including: removal 

of debug information, changing variable names, meiging or splitting live ranges of variables, introducing 
gi irreducible flow graphs, and (particularly in the case of Java) modifying code structures to avoid stereo- 

^ typed forms for source control structures. They have minimal effect on data- and control-flow grs^hs as 

revealed in internal forms used for data-flow analysis by optimizing compilers or program slicing tools. 
Lrreducibilities can be handled by well-known compiler techniques. Information presmt at the 'machine' 
ry code level, or equivalent, is not obscured at all, including the data used in computation. For example, infor- 

5 mation about DES encryption and decryption, and probably any reasonably secure form of encryption or 

H decryption, cannot be hidden effectively using techniques such as these. 

An alternative approach is to enciypt the program either as a whole or in parts, and then to decrypt the pro- 
^ gram or its components temporarily as they are needed. (See [AUG 1 996], for example.) This exposes exe- 

^ cutable images of the program or its components to logic analyzers and the like, permitting recoveiy of the 

^ original program eitiier in entirety, or in a piecemeal fashion as its components are exercised. Moreover, 

imless this paper's subject problem of hiding cTyptographic keys is also solved, &e key can be extracted 

from the software and used to decrypt the entire program. 

The above techniques have the advantage that the size of the code, including any encrypted code, is either 
not increased or increased but little. However, the obfuscation obtained is plainly quite weak, since the 
executed code, control- and data-flow-analyzed in graph form, is either isomorphic to, or nearly isomor- 
phic to, the unprotected code. 

We could also hide the real code by introducing dummy code — say, by making every other statement a 
dummy statement, designed to look much like the real thing. Despite its higher overhead, this approach has 
two &tai weaknesses: (1) It is vulnerable to data-flow analysis (DFA) to discover the redundant dummy 
code, unless extra care is taken to introduce large amounts of aliasing in the dummy code to foil DFA. (2) 
Even if DFA can be rendered ineffective, if xVo of the code is dummy code, then 100 — x% of the code is 
significant For realistic values of x, a patient attacks can locate M^ch statements matter and \^cfa don't 
by trial and error. 

Attempts have been made to hide cryptographic keys by a variety of more specific approaches, including 
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splitting the key into pieces (but the pieces can be reassembled by tracing execution), and modifying the 
algorithm to use a disguised key (but human capacities limit the amount of disguise to a small number of 
algorithmic steps) or a disguised algorithm (but again, with a similar weakness due to the restrictions 
imposed by our limited human capacities). 

In addition, a variety of cryptographically weak approaches have been used for encryption and decryption, 
to avoid the use of any explicit key whatever. These are vulnerable either to a cryptogr^hic black-box 
attack (if a plain>text can be recognized in an automated way) or to algorithmic analysis with the aid of 
debugging tools (since the would*be encryption is then a data transformation of quite limited algorithmic 
complexity). 

In general, then, the state of the art has been that programs could not be made efifectively secret-hiding and 
tamper-proof. Specifically, cryptographic keys for reasonably secure ciphers could not really be hidden in 
software. 

And Now For Something Completely Different! 

In addition to the widely-recognized prindple of obscurity in software protection, our over-all approach to 
tamper-prool^ secret-hiding software involves the following principles: 

L Targeting: We suit the approach specifically to tiie operations to be performed and the data to be 
manipulated. 

2. Partial evaluation: Part of the process of hiding constant input data is to partially evaluate tine applica- 



1^ tion with respect to that data. (In the case of DES key-hiding, for example, the key is constant and is 

eliminated by partial evaluation.) This principle is allied to the principle oidiffusion. 
^ 3. Fusion: Encoded software handles the data in such a way that multiple compon^its are manipulated 

tQ together, so that separating out individual original (i.e., pre-encoding) data operations is difBcult, and 

^ tampering with one entity in effect modifies the behavior of more Aan one entity, 

ry 4. Diffusion: Encoded data and computation distribute information among multiple sites, so that no site 

s alone is sufiicient for understanding, ambiguity is increased, and tampering at individual sites is made 

M' less effective. 

M' 5. Fake robustness: Presimiably, true robustness would preserve the same computation even after some 

forms of tampering. We 'fake' such robustness by avoiding failure responses to data in the presence of 

D tampering. Instead, computation proceeds with z^parent normalcy, but along nonsensical lines. This is 

*fi strongly allied to the principle of anti-holographic behavior, 

6. Anti-holographic behavior: Tampering with a small part of a hologram causes a slight reduction in res- 
olution. We seek the opposite behavior, where the effect of any small diange is to produce large, wide- 
spread^ cascading changes in behavior. 



We now proceed to describe our approach for DES encryption and deciyptioxi, in accordance with die 
above principles. 

Targetii^forDES 

DES inputs a 64-bit block to be encrypted or decrypted and a 64-bit raw key (of which only 56 bits are 
actualty used: the low-order bit of each raw key byte is discarded, or can be used for parity), and outputs a 
64-bit result. 

A description of (single) DES is provided in (FIPS 46-3]. A description and an extensive discussion are 
provided in [SCH 1996]. 

There are only three kinds of data operations in DES: 
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Figure 2: Structure of One DES Round 



1. Selecting some or all bits from a bit-string and re-ordering them into a new bit-string, possibly with 
multiple appearances of certain bits. [SCH 1996] refers to these as permutations^ noting that this is not 
quite accurate since they are not necessarily bijections. Let us refer to such transformations^ in general, 
as quasi'permutations (QPMs), with the true permutations being tiie special case where the QPM is a 
bijection. Each QPM operation is controlled by a table \^ch for each to-hiX of the output bit-string 
gives the ^om-bit in the input bit-string whose value it has, except for key-shift QPMs, which are sim- 
ple rotation pennutations, each of which is described by a simple signed shift count 

2. Bit-wise exclusive or (XOR). 

3. Looking up elements in a table (LKP). In DES, before we perform any transformations, these are look- 
ups in 64-element tables of 4-bit-strings (each of which is called an S-box — S for *'substitution**), 
using a 6-bit-string as an index. Initially, each LKP operation is controlled by one of eight S-box tables 
indicating the substitutions it is to perform. 
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Figure 1 shows the outer structure of DES. We use a specialized presentation designed to emphasize the 
three basic kinds of operations making up DES. Italicized ntmibers adjacent to the arrows indicate die bit- 
widths of the indicated values. QPM a and QPM c are true permutations (no omissions, no duplicated bits), 
with QPM c being the inverse of QPM a. (QPM a is called the initial permutation, and QPM c is called the 
Jinal permutation,') QPM b (die key trcmsfarmation) selects 56 of 64 bits from the raw key, and rearranges 
the bits. The outer box represents the entire DES function (Aether enciyption or deciyption). The inner 
structure of DES comprises 16 rounds of processing, which are identical except for one minor variation in 
the final rotmd and the variations in one of die internal QPM operations (namely, QPM the key shift). 

Figure 2 shows the internal structure of one of the 16 DES rounds. Left In and Right In are the left and 
right halves of the data being processed as it enters the round, and Left Out and Right Out are these halves 
after the processing performed by the rounds. Key In is die 56-bit key as it enters the round, and Key Out is 
die 56-bit k^ as it leaves the round. QPM d (the expansion permutation) repeats certain bits, ^ereas 
QPM / (the compression permutation^ which produces the round sub-key as its output, omits certain bits. 
QPM e (the key shift) consists of rotations of the left and right halves of the 56-bit key by an identical 
amount, in a direction and widi a number of shift positions detennined by the round numbCT and by 
whedier encryption or decryption is being performed. LKP hj-hg (performing S-box substitution) are the 
eight S-box lookups performed in the round. (In the DES standard, the indices for the LKP operations 
h j-hg are each, in effect, preceded by yet another QPM operation, which permutes the six input bits so that 
die low-order or right-most bit becomes the bit second from the left in die effective index, but this QPM 

p can be eliminated to match what we have shown above by re-ordering the elem^ts of the S-box tables.) 

^ QPM I (the P'box permutation) permutes fhc results of I^P h^-hg, presumably to accelerate diffusion of 

yl information across all bits. 

t All rounds are performed identically except for the previously mentioned differences in QPM e (the key 

^ shift) and the swapping of Left Out and Right Out (relative to ^^lat is shown in Figure 2) in die &ial round. 

ru Due to the prevalence of QPM operations, we handle DES operations at the level of individual Boolean 

2 values. At that level, the original QPM operations no longer appear as operations in the data-flow: instead, 

f=^ they simply determine connectivity of the LKP and XOR operations. Note that none of the operations can 

terminate abnormally, irrespective of their inputs, but changing the inputs or the operation changes the 
M= result, so our implementation is completely ftike robust. Moreover, as with many ciphers, slight changes 

S produce cascading, wide-spread behavior^ changes, so that it exhibits anti-holographic behavior (which 

'S we will magnify). 

-S 

^ We also note that the 48 bits emitted by QPM / (the compression permutation) are entirely determined by 

the original key and the round nimiber, since no information travels fix)m die data-portion of the round to 
the key-portion of DES. Hence we unroll the rounds-loop completely, leaving only a directed acyclic graph 
of Boolean operations. In order to avoid multiple-output operations, and to facilitate optimization, we 
replace the eight S-box lookups, LKP hj-hs, with 32 T-box lookups, LKP */-*J2- T stands for "tiny*', since 
only one bit is emitted per T-box. If we regard the bits of the S-box elemmts as columns in a Boolean or bit 
matrix, then each T-box is one column of the corresponding S-box. LKP kj-k^ represent LKP hjt with each 
output representing one bit of the original h 7 output; LKP k^-kg represent LKP h2, and so on. We make the 
T-box lookups in different rounds independent of one another, by copying their tables, so that one round 
can be modified without affecting the others. We then have 16 roimds worth of 32 T-box tables each: 512 
independent T-box tables in all, each containing 64 Boolean elements (since each has six Boolean inputs). 

After the above-described targeting of the operations in DES, the initial connections surrounding one T- 
box operation, LKP kfy appear as shown in Figure 3. 

One further note on targeting: we note that DES is vulnerable to attack from the ends (the beginning and 
end of encryption or decryption; see [SCH 1996]). Hence we note at diis point that we need some way to 
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Figure 4: T-box Connections 
After Partial Evaluation 



increase the protection of the initial and final portions of our implemoitation. 
Partial Evaluation with Respect to die Key 

We note in Figure 3 diat tfie right operands of XOR ntj-m^ are constants. Hence we can delete the right 
operands and replace each XOR witii a Boolean identity (if the constant is false) or a Boolean NOT opera- 
tion (if it is true). We can then eliminate these identities and NOT operations by connecting the LKP 
inputs directly to the operations previously providing inputs to the identities and NOTs. To do this, we 
must adjust the contents of the LKP table to allow for the effect of any inputs resulting fi-om the elision of 
a NOT operation. (This is easily accomplished by re-ordering the elements of the tables.) 

We thai further reduce the operation count by foldmg the XOR shown as XOR n in Figure 3 above 
together with the LKP shown as LKP kf above. To do this, we add a new leftmost input to LKP and con- 
nect it to tiie input to XOR n. We then ehminate XOR n. We take the elements of LKP A,'s table, make a 
copy but with every element inverted, and concatenate that to the end of tiie original table. The result is 
that the new LKP ^KP say) now includes the effect of XOR n (thereby increasing the degree of fiision 
in our implementation) and we now have a version of DBS consisting of 512 7-input T-box lookup opera- 
tions, connected together. The connections of a typical LKP operation, after partial evaluation, are shown 
in Figure 4. 

Information from the key and the manipulations of the key has now been diffused into the T-box LKP 
operations, so we have started to satisfy our principle of diffusion of computations and data. 

The key has now been eliminated from the computation. Note, however, that the connections of a T-box 
LKP from the second previous round, created by eliding the XOR operations of XOR n (see Figure 3) give 
away the identities of the T-box LKPs. We will deal with this problem in a latCT transfonnation. 
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Padding the D£S Implementation 

As part of our targeting, we noted the vuhierability of DBS to attacks starting at the beginning and the end 
of die computation. To address this vuhierability, we padihe DES implementation. 

We generate a series of DES-based identities. A DBS-based identity is created usmg DES implemented 
exactly as described above, except that we omit the effects of the initial and final permutations shown as 
QPM a and QPM c in Figure 1, and we may cut the number of rounds from 16 to some smaller nimiber (as 
low as two). Composition of a pair of tiiese, perfomiing complementary encryption and then matching 
decryption with the same randomly-chosen key, produces a DES-based identity. Each such identity takes in 
64 bits and emits the same 64 bits with no change. 

We pad our implementation by injecting such identities (based on various randomly chosen keys) at vari- 
ous points within our series of unrolled rounds, focussing on the beginning and end of our implementation. 
Since they are identities, they have no effect whatever on the results of our implementation. At this point, 
they do not sound like a sensible addition (after all, identical lineups of 64 Booleans are likely to stick out 
during tracing of the software). However, after further techniques have been applied, they are identities no 
longer. 

These identities, even after further processing, continue to have the property inherent in DES that interfer- 
ing vnth any individual Boolean, or any computation \^ich produces such a Boolean, has a diffuse effect, 
gi altering many bits in future rounds. Hence this padding is not dummy code. It changes what happens in 

Q response to tampering: it contributes to anti-holographic behavior That is, any small change wiU have an 

M» increased tendoicy to produce a wide-spread, cascading effect over many output bits; even more so than in 

yl ordinary DES (with respect to the 'real' rounds). We also address tiie specific need to protect the beginning 

^ and end of the computation. Pads also increase the obscurity of the implementation: there is no longo* just 

^ one key for an attacker to identify in any given hidden-key cryptogriqihic function: there are several. 

SI We may inject further pads at points in die middle of the computation to increase anti-holographic behavior 

1^ ~ as much as we wish. At a minimum, we should enclose a sequence of initial round pairs (one or more) 

r . between two pads, and similarly for a sequence of final round pairs. 

L, Diffusing Information Among T-boxes 

? Here we perform further transformations in accordance with our principle of diffusion of computations and 

^ data. 

For tills transformation, we repeatedly take one T-box (original) and create two corresponding T-boxes 
(left and right), with the same inputs as original, (The original T-box must not be a final output T-box.) 
The tables for left and right are computed so that left does not match rights and neitiier matches original. 
We first present a simple, somewhat weak approach, and then recommend a refinement which makes the 
approach much stronger. Here is the simplified metiiod: 

We choose a Boolean function with two inputs and one output There are 16 of these, but we do not use 
Boolean functions for which some input is a ^don 3f care\ There are six functions we must therefore reject: 
namely, those which output constant true, constant false, the left input, the right input, not the left input, 
and not the right input. The remaining ten Boolean functions are usable, and we choose among such func- 
tions at random for any given left, right pair. Let us denote the function we choose for any particular 
left, right pair by *ftin(f\ 

We fill the tables for left and right as follows: 

For each element indexed by i in original, where i ranges fi-om 0 to 127 inclusive (since the T-boxes have 
seven inputs at the start of this transformation), we choose a pair of values x,y for the left and right ele- 
ments indexed by f, respectively, such that fimc(x,y) has the same value as element i of original. There are 



often multiple choices of Boolean x,y value pairs which achieve this, and we choose randomly among such 
choices. Hence information from original is randomly diffused between left and rights with the addition of 
random, redundant information. 

For any T-box LKP operations which input tiiie value oforiginaU we instead make them input values from 
botfi left and right. This makes them w-input T-box LKPs, where n > 8. (Initially, /i = 8, but as we proceed, 
n may take on higher values with the splitting of more inputs into input pairs,) 

The Boolean value stored in the table of a resulting 8-input T-box LKP operation for any 8-bit input vector 
is determined as follows: Let A and B be bit-strings with a combined laigth of six bits, and let w, v, and w 
be individual bits. We represent concatenation by juxtaposition. For any element indexed by some index 
AwB in tiie expanded 8-input table, the value stored is the same as that of the element indexed by AwB in 
the l-mpxsx table from \^ch it is derived, where w = fiinc(u,v). We handle « > 8 similarly. 

By woridng this transformation backwards from the output T-box LKP operations to the beginning of the 
DES implementation graph, we can arrange that, in general, T-box LKP operations other than those pro- 
ducing tiie final outputs and the initial ones whose inputs are not from other T-box LKP operations, have 
more than seven inputs. 

This transformation is quite simple, and contributes greatly to obscurity, by diffiising information among 
T-box LKP operations and thereby making their contents randomly perturbed relative to their original con- 
tents. Moreover, it tends to make the injected pad identities not quite identities anymore. 

p However, we can make it combinatorially stronger (that is, increase the nimiber of possible functions 

^ above ten), and at the same time tackle the T-box identification problem mentioned at the end of the sec* 

^ tion on partial evaluation, with tiie following refrnemmt: 

gg Instead of having.^c be a function of only two Boolean inputs, we make it a function of three Boolean 

\Q inputs, vfhere one of the inputs is one of the inputs of original which comes from the round previous to 

nj original. Let us caU this extra input p. Then fimc must be a Boolean function sudi that (1) if there is a 

a 'don If care' input, it is the p input, and (2) for each value of p, it is possible to make June return either trne 

or false by modifying the other inputs. This increases the number of choices for June from ten to 1 00. Then 
1=^ LKPs which used to input from original input from all of: lefty right, and the LKP, or the original input 

M from the start of DES, which is the soin*ce of p. 

^« We then replace our uses of Junc(x,y) and fimc{u,v) above with uses of fimcip^y) and func{p,u,v\ respec- 

tively. Filling in the table for the expanded input set is a straightforward extension of tiie methods used 

^ above. In addition to increasing the combinatorial complexity of determining the contents of the diffused 

tables in left and rights this refinement makes it much harder to identify ^^ch T-box LKP corresponds to 
which colmnn of which S-box, since connections from two rounds back become more frequent, and this 
plus a later T-box LKP input permutation step make T-box LKP identities ambiguous. 

It is important to make suitable choices for original and for the source of p. Examination of the intercon- 
nection pattern for T-box LKP operations will show that in many cases we can make the identity of a T- 
box LKP with respect to a column in an S-box ambiguous^ by increasing the number of inputs firom two 
rounds previous from one to two or more, so that it is not clear which input from the second previous round 
came from eliding an XOR (XOR n in Figure 3) and which was added by the diffusion transformation. 
When this is combined with the transformation described in the next section of tiiis paper, which permutes 
the T-box LKP inputs, it makes identification of T-box LKPs with tiieir corresponding S-box columns far 
more difficult, combinatorially speaking. The details depend on the nature of the expansion permutation 
(QPM d in Figure 2) and the P-box permutation (QPM i in Figure 2), which together determine the connec- 
tivity among rounds. 

The above approach, with or without the recommended refinement, easily extends from producing left. 
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right pairs of T-box LKP operations to producing triplets — left, middle, right — or even quadruplets or 
laiger numbers. We can also increase tibe number of inputs in non-tnitial T-box LKP operations^ either by 
producing more pairs, or by producing triplets or quadruplets instead of pairs, or by some combination of 
these approaches. We can also vaiy the number of inputs among T-box LKP operations, making the struc- 
ture of our D£S implementation highly irr^ular. 

Encoding T-box Input Vectors 

In our next step, we encode the input vectors to T-box LKP operations. At this point, flie T-box operations 
have 7- or 8-bit input vectors (or, optionally, larger ones). The encoding consists of (1) flipping randomly 
chosen bits and (2) permuting the positions of the vector elements. 

First, we perform the flipping part of the encoding. We randomly select inputs for inversion. We do this 
only where the soiirces of these inputs are internal to the implemoitation; that is, we do not flip any bits in 
the input data- When a bit is flipped, the bits of its source T-box 's table are inverted. 

Inputs to T-boxes may come jfrom shared sources. As a result, when two T-boxes disagree on the encoding 
of inputs coming from the same other T-box, that source T-box is no longer fully sharable (since its output 
must be delivered to one client flipped and to another unflipped). As a result, this stage increases the num- 
ber of T-box LKP opmtions in the implementation. 

The second part of the coding is to randomly permute the inputs of each T-box LKP op^ation. We re-order 
Q the elements of each T-box LKP table to allow for the new arrangement of the inputs. 

These modifications to the T-box LKP tables intermingle elements ^^ch previously were widely sepa- 
rated, increasing the degree of Jusion in our implementation. They also increase the obscurity, as does the 
presence of multiple T-boxes derived from one T-box, and containing differmt tables. Moreover, the pre- 

^ viously described pad rounds injected into our implementation have now very definitely ceased to be iden- 

S tities. 

Generating an Executable DES Encryption or Decryption Routine 

Up to tills point, we have dealt with a symbolic Boolean DAG, which is not in a form suitable for execu- 
tion on any platform. Note that the DAG consists entirely of T-box LKP operations. A straightforward 
% implementation of DES based on the DAG, then, is as follows: 

iy Each LKP operation is represented by a call to a utility fimction. For an /i-input LKP, it takes « + 1 argu- 

ments. The extra argument is a pointer to the table of Booleans to be used for that particular LKP opera- 
tion. The utility function compresses its inputs into an index, indexes into its table to find the result^ and 
returns that result 

The body of the DES function, then, consists of an initial expansion of the 64-bit input data block into 64 
separate values, followed by a chain of T-box LKP routine calls, plus any needed loads and stores, imple- 
menting the desired Boolean DAG's connectivity, followed by a compression of the 64 result Booleans 
into a 64-bit result value, which is returned. 

We can reduce the number of arguments to each of the above LKP routine calls by one, by taking advan- 
tage of the fact that the calls are chained together in a specific sequential order. Therefore, we can sequence 
tlirough the tables used in the successive calls by having the utili^ routines index through a sequence of 
tables stored in just that sequential order. Thus, the tables can be hnplicit in the calls, instead of being 
passed as an argimient in each call. We would then begin the body of the DES function by settii^ the 
appropriate starting state for iterating through these tables. 
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In Practice, Plain-Text Is Encoded 

Although we described an implementation in which the DES implementation is standard, in practice, we 
would use an encoded implementation in which encrypted information is decrypted to an encoded format 
with bits permuted and some bits flipped. In many contexts, we can compute with such encoded data, and 
using an encoded plain-text form makes the problem of penetrating the DES implementation to find the 
key significantly harder. 



How Hard Is It to Find the Key? 

We have introduced a new way to generate an implementation of DES with an implicit, hidden key. It is 
intended for use where key-hiding is important, but the volume of data to be encrypted or decrypted is 
modest, so that we can tolerate a much slower implementation in order to achieve a greatly increased level 
of security. Our approach injects a huge amount of random, arbitrary information into the structure of the 
hidden-key DES implementation. 

At present, there are, quite simply, no widely-accepted, theoretically well founded metrics for estimating 
flie level of security delivered by a technology for the production of secret-hiding, tamper-proofing soft- 
ware. This is a vast unexplored area in the theory of computational complexity. 

^ Any theory covering such an area must deal with the computational complexity of moving fi-om one level 

of abstraction to another. It must provide a basis for comparing a distance between two programs in terms 
P of their respective codes ^ to a distance between them in terms of their respective behaviors^ so that the 

I- effects of tampering can be gauged. (For a tamper-proo^ seoret-hiding program, we would expect tamper- 

^ ing ^\^ch traverses only a small distance by the code metric to produce a behavioral change \\iiich 

J traverses a huge distance by the behavior metric; that is, we would expect anti-hologreqihic behavior) 

%0 We most eagerly await theoretical and practical work in this area! 

_ The way S-box LKP operations are interconnected v/hen we unroll the round loop of DES determines the 

way the T-box LKP operations are interconnected -when we convert fi-om S-box LKPs to T-box LKP oper- 
ations and then pardaily evaluate with respect to the key, (The key has no effect on connectivity.) This 
would allow us to identify the T-box LKPs. However, after we perform the refined version of diflRision of 
Q information into pairs of T-box LKP tables, followed by encoding of T-box LKP input vectors, which per- 

^ mutes the inputs, T-box LKP identification is ambiguous. While analysis of the combinatorial complexity 

&f! of T-box identification is a dauntingly difficult undertakmg, it se^ns clear that diese transformations make 

the problem of identifying the effective positions of individual T-box LKP operations, as compared to col- 
umns of the original S-boxes, a combinatorially sizable search problem. 

Even if we could identify all of the T-box LKJ*s with individual columns in mdividual original S-boxes, 
however, we would still not know the key. Due to padding, an attacker must contend with multiple keys 
and unknown boundaries between pad rounds and *real' roimds. The difficulty of finding the *real' key can 
be increased by using more injected pads, or pads with more rounds, ch* botii. Due to the encoding and dif- 
fiising of information among tables, and due die large size of the combinatorial search for ways to disam- 
biguate T-box LKP identities and then recombine diffused pairs of LKPs back into single LKPs, we 
believe that we have created an extremely large combinatorial guessing problem to find the key. We can 
make this problem harder by increasing the number of inputs in the T-boxes — thereby making more and 
more T-box tables the result of combinatorially hidden diffused information. Exact computation of the 
search problem's complexity is difScult, even if most T-box LKPs have only eight inputs, but the combina- 
torial complexity of the guessing problem appears likely to be massive, even with a small number of mini- 
mal pads surrounding only the initial and final round pairs of our DES implementation. 

Our ^proach is obviously far more obscure than previous approaches to key-hiding. At present, the stron- 




gest method we can propose for estimating the security of our approach is to provide a web site at vidiich 
sample DES encryption and decryption functions are provided for known keys, plus challenge implemen- 
tations with unknown keys (the objective being to identify the unknown keys). As of die date of this con- 
foence, diis site {identifying URL suppressed) is available. We are confident that our unplementation 
techniques will stand up weU to concerted attacks: experience should indicate decisively whedier our con- 
fidence is well-founded. 

Conclusion 

The state of the art in software tamper-proofing and obfuscation in general, and hiding of cryptographic 
keys in sofhvare in particular, has been quite weak. We have described an approach which is far more 
secure at the cost of increased overhead, and suggested applications for it. We note that metrics for measur- 
ing the security of such technologies represent a vast unexplored area in computational complexity. 
Accordingly, we invite challengers to attempt to crack our technology for hiding ciyptographic keys in 
software. Facilities for such attempts will be provided at our web site 
(http : / /www . cloakware . com). 
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